<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>技术文档页面</title>
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <nav id="navbar">
      <header>Git</header>
      <ul>
        <li>
          <a href="#Getting_Started" class="nav-link">Getting Started</a>
        </li>
        <li>
          <a href="#Git_Basics" class="nav-link">Git Basics</a>
        </li>
        <li>
          <a href="#Git_Branching" class="nav-link">Git Branching</a>
        </li>
        <li>
          <a href="#Git_on_the_Server" class="nav-link">Git on the Server</a>
        </li>
        <li>
          <a href="#Distributed_Git" class="nav-link">Distributed Git</a>
        </li>
      </ul>
    </nav>
    <main id="main-doc">
      <section class="main-section" id="Getting_Started">
        <header>Getting Started</header>
        <li>1.1 关于版本控制</li>
        <p>
          什么是版本控制？我为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。在本书所展示的例子中，我们仅对保存着软件源代码的文本文件作版本控制管理，但实际上，你可以对任何类型的文件进行版本控制。
        </p>
        <p>
          如果你是位图形或网页设计师，可能会需要保存某一幅图片或页面布局文件的所有修订版本（这或许是你非常渴望拥有的功能）。采用版本控制系统（VCS）是个明智的选择。有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着，就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。
        </p>
        <li>1.2 Git 简史</li>
        <p>
          同生活中的许多伟大事件一样，Git 诞生于一个极富纷争大举创新的年代。Linux
          内核开源项目有着为数众广的参与者。绝大多数的 Linux
          内核维护工作都花在了提交补丁和保存归档的繁琐事务上（1991－2002年间）。到 2002
          年，整个项目组开始启用分布式版本控制系统 BitKeeper 来管理和维护代码。
        </p>
        <li>1.3 Git 基础</li>
        <p>
          那么，简单地说，Git
          究竟是怎样的一个系统呢？请注意，接下来的内容非常重要，若是理解了 Git
          的思想和基本工作原理，用起来就会知其所以然，游刃有余。在开始学习 Git
          的时候，请不要尝试把各种概念和其他版本控制系统（诸如 Subversion 和 Perforce
          等）相比拟，否则容易混淆每个操作的实际意义。Git
          在保存和处理各种信息的时候，虽然操作起来的命令形式非常相近，但它与其他版本控制系统的做法颇为不同。理解这些差异将有助于你准确地使用
          Git 提供的各种工具。
        </p>
      </section>
      <section class="main-section" id="Git_Basics">
        <header>Git Basics</header>

        <li>2.1 取得项目的 Git 仓库</li>
        <p>
          有两种取得 Git
          项目仓库的方法。第一种是在现存的目录下，通过导入所有文件来创建新的 Git
          仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。
        </p>
        <p><strong>在工作目录中初始化新仓库</strong></p>
        <code>$ git init</code>
        <p><strong>克隆现有的仓库</strong></p>
        <code>$ git clone [url]</code>

        <li>2.2 记录每次更新到仓库</li>
        <p><strong>检查当前文件状态</strong></p>
        <p>
          要确定哪些文件当前处于什么状态，可以用 git status
          命令。如果在克隆仓库之后立即执行此命令，会看到类似这样的输出：
        </p>
        <code>
          $ git status # On branch master nothing to commit (working directory clean)
        </code>

        <p><strong>跟踪新文件</strong></p>
        <p>使用命令 git add 开始跟踪一个新文件。所以，要跟踪 README 文件，运行：</p>
        <code> $ git add README </code>

        <li>2.3 查看提交历史</li>
        <p>
          在提交了若干更新之后，又或者克隆了某个项目，想回顾下提交历史，可以使用 git log
          命令查看。 接下来的例子会用我专门用于演示的 simplegit
          项目，运行下面的命令获取该项目源代码：
        </p>
        <code> git clone git://github.com/schacon/simplegit-progit.git </code>
      </section>
      <section class="main-section" id="Git_Branching">
        <header>Git Branching</header>
        <li>3.1 何谓分支</li>
        <p>
          在 Git
          中提交时，会保存一个提交（commit）对象，该对象包含一个指向暂存内容快照的指针，包含本次提交的作者等相关附属信息，包含零个或多个指向该提交对象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先。
        </p>

        <li>3.2 分支的新建与合并</li>
        <p>要新建并切换到该分支，运行 git checkout 并加上 -b 参数：</p>
      </section>
      <section class="main-section" id="Git_on_the_Server">
        <header>Git on the Server</header>
        <li>4.1 协议</li>
        <p>
          Git 可以使用四种主要的协议来传输数据：本地传输，SSH 协议，Git 协议和 HTTP
          协议。下面分别介绍一下哪些情形应该使用（或避免使用）这些协议。
        </p>
        <p>
          值得注意的是，除了 HTTP 协议外，其他所有协议都要求在服务器端安装并运行 Git。
        </p>
        <li>4.2 在服务器上部署 Git</li>
        <p>
          开始架设 Git 服务器前，需要先把现有仓库导出为裸仓库 —
          即一个不包含当前工作目录的仓库。做法直截了当，克隆时用 --bare
          选项即可。裸仓库的目录名一般以 .git 结尾，
        </p>
      </section>
      <section class="main-section" id="Distributed_Git">
        <header>Distributed Git</header>
        <li>5.1 分布式工作流程</li>
        <p>
          同传统的集中式版本控制系统（CVCS）不同，开发者之间的协作方式因着 Git
          的分布式特性而变得更为灵活多样。在集中式系统上，每个开发者就像是连接在集线器上的节点，彼此的工作方式大体相像。而在
          Git
          网络中，每个开发者同时扮演着节点和集线器的角色，这就是说，每一个开发者都可以将自己的代码贡献到另外一个开发者的仓库中，或者建立自己的公共仓库，让其他开发者基于自己的工作开始，为自己的仓库贡献代码。于是，Git
          的分布式协作便可以衍生出种种不同的工作流程，我会在接下来的章节介绍几种常见的应用方式，并分别讨论各自的优缺点。你可以选择其中的一种，或者结合起来，应用到你自己的项目中。
        </p>
        <li>5.2 为项目作贡献</li>
        <p>接下来，我们来学习一下作为项目贡献者，会有哪些常见的工作模式。</p>
        <p>
          不过要说清楚整个协作过程真的很难，Git
          如此灵活，人们的协作方式便可以各式各样，没有固定不变的范式可循，而每个项目的具体情况又多少会有些不同，比如说参与者的规模，所选择的工作流程，每个人的提交权限，以及
          Git 以外贡献等等，都会影响到具体操作的细节。
        </p>
        <p>
          首当其冲的是参与者规模。项目中有多少开发者是经常提交代码的？经常又是多久呢？大多数两至三人的小团队，一天大约只有几次提交，如果不是什么热门项目的话就更少了。可要是在大公司里，或者大项目中，参与者可以多到上千，每天都会有十几个上百个补丁提交上来。这种差异带来的影响是显著的，越是多的人参与进来，就越难保证每次合并正确无误。你正在工作的代码，可能会因为合并进来其他人的更新而变得过时，甚至受创无法运行。而已经提交上去的更新，也可能在等着审核合并的过程中变得过时。那么，我们该怎样做才能确保代码是最新的，提交的补丁也是可用的呢？
        </p>
      </section>
    </main>
  </body>
</html>
